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SYSTEM AND METHOD FOR REPORTING AND DELIVERING CALLS 

5 RELATED APPLICATIONS 

This application is a continuation-in-part of U.S. Application No. 
09/441,822, filed November 17, 1999, which claims the benefit of U.S. Provisional 
Application No. 60/108,731, filed November 17, 1998, both of which are hereby 
incorporated herein by reference in their entireties. 

10 

FIELD OF THE INVENTION 

This invention relates in general to call record reporting, and more 
particularly to a system and method for arranging, reporting, and delivering call 
record information to customers. 

15 

BACKGROUND OF THE INVENTION 

Current telecommunications networks are capable of tracking and 
recording call transaction data, i.e., information associated with a given telephone 
call, and using this data to support call processing and to provide accurate billing 

20 information to customers. Systems have also been developed which strive to 
provide the customer with quite detailed call transaction data which the customer 
may use for specific purposes. U.S. Patent No. 5,425,087 to Gerber, for example, 
discloses a system that reports the length of each call, the length of time that a party 
was placed on hold, and the telephone number of the other party to a system 

25 administrator so that the telephone activities of employees can be monitored in real 
time. 

U.S. Patent No. 5,754,634 to Kay, et al. discloses a system for 
tracking calls made to individual predetermined subscribers and automatically 
reporting information, including demographic breakdowns of calls, such as time of 
30 day, day of week, and location of origin, to the subscriber. The disclosed system 

makes use of the Advanced Intelligent Network (AIN) and Integrated Service Control 
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Point (ISCP) platform to provide such information to those subscribers desirous of 
such service. The ISCP captures the time and date of the call, the originating call 
number and the subscriber's call number. ISCP network data is collected for all 
calls placed to service subscribers by the AIN Data and Reports System (DRS). 
5 DRS is an operation support utility that provides service analysis on the collected 
data. The data may be sorted on the basis of called subscriber number and 
transmitted at periodic intervals to a report processor. 

The call originating telephone number for each call may be used to 
access an existing telephone system billing database to obtain caller information, 

10 including zip code. The zip code, in turn, can be used to access a commercially 
available census database to provide further demographic information. For 
example, demographics for a given zip code may include median age and median 
income. Report statistics can match these demographics with a number of calls 
received as collected at the ISCP. 

15 The calling party number may be supplied through Caller ID or AIN 

transmission. If this information is available only for calls within a telephone 
company Local Access and Transport Area (LATA), reports may include detailed 
breakdown of such calls while categorizing out of LATA calls in more general 
breakdowns. Detailed zip code results can include number and percentage of 

20 residential calls, business calls, homeowners, median income and age. Generalized 
information may include numbers, averages and percentages of calls in time ranges 
for days of the week. 

The existing arrangements have some drawbacks. In the existing 
arrangements, a zip code cannot be attached to certain calls. For example, 

25 because a telephone company has no billing records for telephone numbers outside 
of its LATA, it cannot attach a zip code to long distance calls. Further, under the 
existing arrangement, there is no way to attach a geographical indicator to a call 
without a zip code. Thus, for many calls, no geographical indicator can be 
attached. Furthermore, even for calls for which a zip code is attached, there is no 

30 indication of an actual geographic location. All the subscriber receives is a zip code. 
Another drawback of the existing arrangements is that the report that is output to the 
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subscriber is only available in tabular form, which tends to be rather cryptic. Thus, it 
is difficult and inconvenient for the subscriber to comprehend and absorb the 
information contained in the tables. Further still, the prior art does not facilitate 
convenient call record report delivery. 

There is a need in the telecommunications industry for a system and 
method of providing accurate call records, and providing such records to service 
subscribers in a convenient manner. The present invention fulfills these and other 
needs, and provides additional advantages over the prior art. 



Page 3 

ALG 1 375.301 -US-11 

Patent Application 



4 , 

SUMMARY OF THE INVENTION 

To overcome limitations in the prior art described above, and to 
overcome other limitations that will become apparent upon reading and 
understanding the present specification, the present invention generally discloses a 
5 system, apparatus and method for arranging, reporting, and delivering call record 
information to customers. 

In accordance with one embodiment of the invention, a method is 
provided for reporting communication records to at least one subscriber. The 
communication records of each subscriber includes call transaction data 

10 corresponding to call transaction activity of the subscriber. The method includes 
receiving the call transaction data, and matching the call transaction data associated 
with the subscriber. The call transaction data is appropriately formatted, and 
electronically transmitting the formatted call transaction data to the subscriber. One 
exemplary manner of electronically transmitting the formatted call transaction data is 

15 via electronic mail (e-mail). In accordance with other aspects of the invention, a call 
reporting apparatus, and a computer-readable medium having instructions for 
carrying out these functions are also provided. 

In accordance with another embodiment of the invention, a method is 
provided for reporting calls having associated call transaction data, where the calls 

20 are communications between a subscriber and at least one second caller. The 
method includes accessing the call transaction data and identifying the subscriber 
associated with each call. An approximate longitude and latitude of the second 
caller is determined for each call using the call transaction data, and a call report 
including the approximate longitude and latitude for each call is delivered to the 

25 subscriber associated with the call. 

In accordance with another embodiment, a method is provided for 
reporting call records of calls involving a call party. Each of these calls have 
associated call transaction data. The method includes accessing the call 
transaction data, identifying the call party associated with each call, and verifying the 

30 validity of the call transaction data. A statistical report related to the call transaction 
data is generated if the call transaction data is valid, and the statistical report is 
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delivered to the call party via electronic mail (e-mail). 

Yet another embodiment of the invention involves a method for 
reporting calls having associated call transaction data, where the calls are 
communications between at least first and second callers. The method includes 

5 accessing the call transaction data and identifying a caller associated with each call. 
The call transaction data is analyzed to determine an approximate geographical 
reference related to each call. A plurality of variable telecommunication transaction 
attributes associated with each call and correlated to the geographical reference for 
each call are electronically delivered to at least one caller. 

1 0 These and various other advantages and features of novelty which 

characterize the invention are pointed out with particularity in the claims annexed 
hereto and form a part hereof. However, for a better understanding of the invention, 
its advantages, and the objects obtained by its use, reference should be made to the 
drawings which form a further part hereof, and to accompanying descriptive matter, in 

15 which there are illustrated and described specific examples of an apparatus in 
accordance with the invention. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The invention is described in connection with the embodiments 
illustrated in the following diagrams. 

FIG. 1 is a high level block diagram of a system in which the principles 
5 of the present invention may be applied; 

FIG. 2 is a block diagram Illustrating one embodiment of telephone 
company call processing in accordance with the invention; 

FIG. 3 is an example of a call record, which in one embodiment Is 
provided by the telephone company for processing in accordance with the present 
10 invention; 

FIG. 4 is a block diagram illustrating one embodiment of call 
processing according to the present invention; 

FIG. 5 is a block diagram illustrating one embodiment of end-of-cycle 
processing according to the present invention; 
15 FIG. 6 Is a block diagram illustrating one embodiment of web report 

distribution in accordance with the present invention; 

FIG. 7 is a block diagram illustrating one embodiment of storage media 
report distribution according to the present invention; 

FIG. 8 is a table exemplifying call detail data that may be produced 
20 according to the present invention; 

FIG. 9 illustrates an exemplary geocoding logic hierarchy according to 
the present invention; 

FIG. 10 is a flow diagram illustrating representative examples of 
delivery features associated with the call reporting methodology of the present 
25 invention; 

FIG. 1 1 is a flow diagram illustrating an embodiment of a call reporting 
methodology utilizing e-mail delivery in accordance with the invention; 

FIG. 12 provides an example of an e-mail report layout as received by 

a subscriber; 

30 FIG. 13 illustrates various graphical representations of the call report 

data, including maps, graphs, charts, and structured data such as spreadsheets; 
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FIG. 14 illustrates a message content table used to store the content 
of the message that will be sent to the subscriber; 

FIG. 15 illustrates a user table used to store all active subscribers of 
the call reporting service; 
5 FIG- 16 illustrates a variable table used to store the variables that may 

be to build the resulting message; 

FIG. 17 is a diagram identifying an exemplary list of variables that may 
be used in the message content; 

FIG. 18 is a flow diagram illustrating an embodiment of an e-mail 
1 0 generation methodology in accordance with the invention; 

FIG. 19 is a flow diagram illustrating one embodiment of an e-mail 
processing methodology in accordance with the present invention; 

FIG. 20 is a diagram illustrating an exemplary view of a main report 
screen that may be generated by a report generator in accordance with the present 
15 invention; 

FIG. 21 is a diagram illustrating an exemplary view of a calendar 
selection screen that may be generated according to the present invention; 

FIG. 22 is a diagram illustrating an exemplary view of a user interface 
screen in which the report format and/or report parameters may be selected or 
20 modified according to the present invention; 

FIG. 23 is a diagram illustrating a table exemplifying a report that may 
be generated by the report generator according to the present invention; 

FIG. 24 is a diagram illustrating a graph exemplifying a report that may 
be generated by the report generator according to the present invention; 
25 FIG. 25 is a diagram illustrating a map exemplifying a report that may 

be generated by the report generator according to the present invention; and 

FIG. 26 is a diagram illustrating a more specific map of a report that 
may be generated by the report generator according to the present invention. 
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DETAILED DESCRIPTION OF THE INVENTION 
In the following description of the exemplary embodinnent, reference is 
made to the accompanying drawings which form a part hereof, and in which is 
shown by way of illustration the specific embodiment in which the invention may be 
5 practiced. It is to be understood that other embodiments may be utilized, as 

structural and operational changes may be made without departing from the scope 
of the present invention. 

Generally, the present invention provides a system and method for 
reporting call transaction information. The system in receives call transaction data 

1 0 and processes it for each subscriber by generating information in a format that can 
be perceived by the subscriber in a convenient fashion. The information is delivered 
to the subscribers, and presented to the subscriber as a call transaction report. A 
variety of delivery methods may be used in connection with the present invention, 
such as an e-mail delivery. 

1 5 The present invention is applicable to a wide variety of 

communications systems and methodologies. The present invention is particularly 
useful in connection with telephone call records associated with telephone 
companies, and therefore a significant portion of the ensuing description is 
described in terms of an implementation associated with telephone records and 

20 telephone companies. However, as will be readily apparent to those skilled in the 
art from a reading of the description provided herein, other types of communications 
records, systems, and entities are clearly within the scope of the invention, and the 
invention is thus not limited to the exemplary telephone record embodiment provided 
herein. 

25 FIG. 1 provides an overview of an exemplary system implementing the 

principles of the present invention. FIG. 1 provides a block diagram of a system 
according to the invention, including a telecommunications company 10, service 
provider 14, and customer 26. In block 10, the telecommunications, such as a 
telephone company, captures and processes call transaction data for customers 

30 who subscribe to a reporting service employing the system of the present invention. 
The telecommunications company 1 0 transmits the call records as shown via path 
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12, via a global computer network (such as the Internet) or other appropriate data 
transmission mechanism, to the provider of the sen/ice embodied in the present 
invention. The telecommunications company 10 may represent any 
telecommunications entity having switching, routing, bridging or other technology in 

5 which the call data can be intercepted and processed in accordance with the 

invention. For example a telephone company switch or router, Internet node where 
Internet calls traverse the node; wireless communication base station, and the like. 
In one particularly useful embodiment of the invention, the telecommunications 
entity is a telephone company, such as a Regional Bell Operating Company 

10 (RBOC). 

In block 14, the service provider processes the call records received 
from the telephone company 1 0. In order to do this, a number of functions are 
performed. The functions associated with one embodiment of the invention are 
illustrated by blocks in service provider call processing block 14, and can be 

15 performed by any suitable, computer-based systems. In block 16, the system 
converts the call record data into a format that is compatible with the system's 
geocoding software and report-generating software. Also in block 16, the call 
records are matched to the subscriber. In block 18, the system audits and verifies 
the validity of the data. In block 20, the system geocodes the call data. Thus, for 

20 each call, the system attaches a geographic longitude and latitude corresponding to 
the location of the second party to the call (the subscriber being the first party to the 
call). In block 22, the call records and the geocoded data are packaged into a call 
detail file. Block 24 represents the delivery of the call detail data, which can be 
delivered to the subscriber in a suitable way. For example, these delivery methods 

25 include delivery via the Internet 24a or other network transmission, and storage 
media 24b such as floppy disks, CD-ROM, tape or other storage media. Delivery 
may also be in paper form 24c via postal mail, fax, etc., and/or via wireless data 
transmission, electronic mail (e-mail) 24d, or other forms of electronic data delivery 
24e. In one more recent embodiment, the delivery method may include, for 

30 example, a wireless application protocol (WAP) delivery that can be received via a 
WAP-compliant wireless device operated by the subscriber. 
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Block 26 illustrates that the call detail data is fed into a report 
generator that outputs a report in a format, which in one embodiment, is selected by 
the subscriber. The format may also be determined by the service provider or other 
authority, or may be predetermined. In one embodiment, the report generator is run 

5 by the subscriber on the subscriber's own receiving device such as a computer 
(unless the subscriber opts for paper delivery, in which case the service provider 
generates the report). It should be recognized that the receiving device includes 
any electronic device capable of receiving electronic data, such as computing 
devices, personal digital assistants (PDAs), data-capable wireless devices such as 

10 WAP devices, and the like. In the present example, the receiving device is a 

computing device operated by the subscriber. The available report formats include 
a variety of tables, graphs and maps. If the subscriber selects, for example, the 
map format, the report generator overiays the geocoded data on a map so that the 
subscriber can see on the map exactly where calls were placed to or received from 

1 5 along with various other information regarding those calls. 

FIG. 2 provides an illustrative example of the call processing 
performed by a communications entity, such as a telephone company as shown in 
block 10 of FIG. 1 . It should be noted that different telephone companies will 
process their call records in different ways. The present invention is capable of 

20 adjusting to the particular processing method employed by a given communications 
or telephone company. It should also be noted that different telephone companies 
will transmit their call records to the service provider at different points along the 
chain illustrated in FIG. 2. 

In FIG. 2, at its various switches 28, the telephone company captures 

25 call transaction data off of the Advanced Intelligent Network (AIN) and places the 
data in AIN call files 30 of two types: call attempt files and completed call files. The 
call attempt files contain call transaction data for all attempted calls, while the 
completed call files contain call transaction data for all calls. Call transaction data 
can include the time, date and duration of the call, the originating call number, the 

30 terminating call number, and call status (busy, answered or unanswered). Because 
the present invention can be used with both outgoing and incoming calls, the 
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subscriber's line number may be either the originating or the terminating call 
number. The telephone company then combines the AIN call files from its various 
switches into a single call attempt file and a single completed call file, as shown in 
block 32. 

5 In block 34, the billing records, including billing telephone number 

(BTN) and zip code, of the second party to each call are added to the call 
transaction data files. Billing records may not be available for some calls (long 
distance calls, for instance). In this illustrative embodiment, the step embodied in 
block 34 is performed by the telephone company. However, the present invention is 

1 0 also capable of performing this step, as well as all subsequent steps. 

Next, the AIN call attempt file 36 and the AIN completed call file 38 are 
combined to form one complete call record file, as shown in block 40. This call 
record file is then transmitted to the service provider by sending it to the service 
provider's FTP (File Transfer Protocol) server 42, or other appropriate means. In 

15 one illustrative embodiment, the telephone company will transmit the call record 
data to the service provider at least daily, but may be transmitted at any 
predetermined dates/times or any predetermined periodicity. 

FIG, 3 is a printout of a sample single call record 44 that might be 
transmitted from the telephone company to the sen/ice provider. Some of the 

20 significant fields include the subscriber billing telephone number 46, the number of 
the subscriber's line 48 used for the call, the time 50 and date 52 of the call, the line 
number of the calling party 54, the zip code of the calling party 56, call type 58 and 
duration 60. Different telephone companies may transmit call records of varying 
formats. For instance, the call type field 58 of one telephone company might 

25 Indicate whether the call was answered, unanswered or met with a busy signal, 
while for a different telephone company might indicate whether the call was 
incoming or outgoing. Also, the subscriber has the option of receiving records for 
incoming calls, outgoing calls or both, and the call record will vary accordingly. 

FIG. 4 provides a detailed breakdown of the call processing performed 

30 by the service provider as shown in block 14 of FIG. 1 . The service provider 
receives the call record files from the telephone company by any appropriate 
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means. In FIG. 4, the service provider receives the call record data at its secured 
FTP server 42, as shown in block 62. In block 64, the FTP server is scanned for 
files received. Also in block 84, when raw files 66 are received, they are transferred, 
in one illustrative embodiment, to a local area network processing server. 

5 In block 68, the validity of the call record data 66 is checked. The 

system searches for anomalies in the data by performing statistical analysis to 
determine if certain variables fall within established parameters. Examples of 
variables that are analyzed include the number of calls received, the number of busy 
calls received and the number of calls for which the status is unknown in a given 

1 0 time period. The system may also check to ensure that calls were received during 
all hours of the day to determine whether data transmission problems were 
encountered during any time of the day, or to determine whether the system was 
temporarily down during any part of the day. The current data is compared to 
collected statistical data to determine if the current data is generally in line with the 

15 collected data. The parameters will vary from one subscriber to another. For 

example, for one subscriber it may be acceptable for five percent of its calls to be of 
unknown status, while for another subscriber, one percent may be the highest 
acceptable percentage of calls of unknown status. The system adjusts the 
parameters over time and for new situations as new statistical data is collected. The 

20 validity check is performed at the overall level, as well as the individual subscriber 
level. For example, at the overall level, the system compares the newly received 
files 66, in the aggregate against the statistical data maintained for aggregate files. 
Then, the same types of checks are performed on the individual customer basis. If 
the call record data is deemed invalid, it is kicked out of the system and not 

25 processed further, as shown in block 70. If the data is deemed valid, processing 
continues at block 72. 

In block 72, the system verifies that the subscriber's account was 
active when the particular call was placed. If the account was terminated or not yet 
active, the data is not processed, as shown in block 74. In block 76, the call record 

30 data is converted into a format that is compatible with the service provider's 
geocoding software and report-generating software. Also in block 76, the call 
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records are matched to the subscriber. In some cases, the telephone company will 
provide the customer number as part of the call record data. When that is the case, 
the system looks up the customer records in both a customer master file 78 and line 
cross-reference file (line xref) 80. The customer master file contains customer 
5 information (related to a given customer number) collected during an initial set-up 
procedure in which the customer's account is Initialized. The cross-reference file 80 
contains a cross-reference between particular telephone line numbers and customer 
numbers. If the customer number is not in the customer master file 78 and the line 
number is not in the line cross-reference file 80, the call record is placed in a spin 

10 file for a suitable period of time (such as one month) and processing is re-tried at 
that time, as shown in block 82. 

If the telephone company does not provide the customer number, the 
system looks up the customer number in the line cross-reference file 80. If the line 
number is not in the line cross-reference file 80, again the call record is placed in the 

15 spin file for one month, as shown in block 82. Thus the output of block 72 is a good 
call record file in the service provider's format 84. 

In block 86, the call record data is geocoded. The geocoding process 
attaches to each call the precise longitude and latitude of the geographic centroid, 
or geographic center, of either the zip (postal) code, area code or exchange code of 

20 the second party to the call. Five geographic databases 88 are maintained, one 
each for nine-digit zip codes, five-digit zip codes, three-digit zip codes, area codes, 
and exchange codes. Each database contains the precise longitude and latitude of 
the geographic centroid for each respective zip, area and exchange code. FIG. 9 
illustrates an exemplary geocoding hierarchy. 

25 In case-1 180, a nine-digit zip code exists in the call record's zip code 

field. If the same nine-digit zip code exists in the nine-digit zip code database, the 
longitude and latitude corresponding to that zip code are attached to that call. If the 
nine-digit zip code is not contained in the nine-digit database, the system looks in 
the five-digit zip code database for the first five digits of the nine-digit zip code. If 

30 that five digit zip code is present, the corresponding longitude and latitude are 

attached to the call. If the first five digits are not in the five-digit database, the three- 
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digit database is searcfied for the first three digits of the nine-digit zip code. The 
three-digit database may be useful, for instance, for new zip codes which are not yet 
cataloged in the five-digit database. If the first three digits do not exist in the three- 
digit database, the system searches the exchange code database (designated 

5 npanxx DB in FIG. 9) for the first six digits (designated npanxx) of the line number of 
the second party to the call (i.e., the area code and exchange). The exchange code 
database contains data corresponding to particular exchange codes within particular 
area codes. An exchange code consists of the first three digits of a telephone 
number after the area code. Thus, if a match is found in the exchange code 

1 0 database, the longitude and latitude corresponding to the geographic centroid 
corresponding to the identified area code and exchange are attached to the call 
record. If no match is found in the exchange code database, the area code 
database (designated nap DB in FIG. 9) is searched for the area code (designated 
npa) of the line number. If that is unsuccessful, a special longitude/latitude value 

1 5 indicating unknown origin is attached to the call. 

In case-3 1 84, a five-digit zip code is provided in the zip code field. If a 
five-digit zip code exists 'in the call record's zip code field, a protocol similar to the 
above is used as shown in FIG. 9, beginning with a search of the five-digit zip DB 
and continuing on as described with respect to case-1 180. 

20 As can be seen in case-2 182, case-4 186 and case-5 188 of FIG. 9, if 

less than five or between five and nine (i.e., six, seven or eight) digits exist in the call 
record's zip code field, the system presumes that the data is invalid and uses only 
the line number in geocoding that call as described with respect to case-1 180. 

The system also assigns a value, shown in the far right-hand column 

25 of FIG. 9, to the longitude and latitude specification based on its precision. For 
example, when the nine-digit zip code database is used to determine the longitude 
and latitude, a more accurate approximation of the location of the second party to 
the call is obtained than if the five-digit or three-digit databases are used. The 
assigned value reflects this degree of accuracy. The assigned value can also be 

30 used to indicate the reliability of the data. For example, in case-2 1 82 and case-4 
186, it is presumed that the zip code field in the call record contains bad data. 
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There is then an increased probability that other data in the record, including the line 
number, is also unreliable. The assigned value reflects this reduced level of 
reliability. 

The description now continues with respect to FIG. 4. In block 86, the 

5 customer accumulator and line accumulator are also updated. The accumulators 
tally the number of call records processed during the current cycle for each line and 
for each subscriber. Cycles may be any predetermined time period, such as daily, 
weekly, monthly, etc. The output of block 86 is the call detail data 90 which is the 
aggregate of the call record data 84 and the corresponding geocoded data. The call 

1 0 detail records 90 are accumulated until the end of the cycle, at which time they are 
prepared for distribution to the subscriber. The call detail records are also stored in 
the customer balance and line balance databases 92, which are used in the validity 
checks of block 68 and against which statistical analysis is performed. 

FIG. 5 illustrates the processing of the call detail records which takes 

15 place at the end of each cycle. The system first obtains the identity of a customer 
for which a cycle has ended and to which call detail records must be reported. This 
is indicated by block 93. In block 94, the system checks whether records have been 
processed for the given line or given subscriber (depending on whether calls are to 
be processed for all of the subscriber's lines or for just a given line) during the 

20 current cycle. If records have been processed, the call detail records 90 are 

collected as shown in block 96. In block 98, the system checks whether the number 
of call detail records 90 is equal to the value held in the accumulator 1 00. If it is not, 
there may be a problem with the call detail records 90 and the process is halted, as 
shown in block 102. If the accumulator 100 agrees with the call detail records, the 

25 calls are sorted as indicated by block 1 04 and cycle processing commences as 
indicated in block 1 06. 

In block 108, a customer delivery summary file 1 10 is created. This 
file contains information regarding the subscriber's delivery preferences. This file is 
created using information obtained from the customer master file 78 and line cross- 

30 reference file 80. In block 112, a marketing message file 114 is created. The 

marketing message represented in the marketing message file may, for instance, be 
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a logo, 'company name or other message and will later be placed on the output 
reports. This message Is typically created by the telephone company. The 
customer delivery summary file 110 and customer message file 1 14 are then 
merged into a single summary/message file 116, which is used to determine 

5 whether the reports will be delivered to the subscriber in paper form, or via storage 
media such as floppy disk, the Internet, e-mail, wireless transmission, or other 
suitable mechanism as shown in block 118. 

The report data can be delivered to the subscriber by any of a variety 
of methods. In one embodiment, the subscriber chooses the delivery method. 

1 0 Some representative delivery methods, as previously indicated, include delivery via 
the Internet, direct dial-up, e-mail, diskette, CD-ROM, wireless transmission, paper, 
etc.. Of course, other transmission methods may be used as well. 

For purposes of illustration, embodiments of Internet and diskette 
distribution methods are shown in FIGS. 6 and 7 respectively. FIGS. 6 and 7 

1 5 correspond to block 24 In FIG. 1 . In accordance with the illustrated embodiments, a 
file is created in an electronic reporting format, such as a .PDF (paper document 
format) file, as shown at block 120. A self-extracting executable file (e.g., .EXE file) 
is created, as shown at block 122. In the case of web distribution, the files are 
copied to the service provider's Internet server delivery directory, as shown at block 

20 124. At block 126, the service provider's web page is updated to avail the new files 
to the subscriber. The subscriber can retrieve the files at the service provider's web 
site. In the case of storage media (e.g., diskette) distribution, the .PDF and .EXE 
files are copied 128 to the customer sen/ice delivery directory, and then copied to 
the disk 130. The disk 130 or other such storage media can then be delivered to the 

25 subscriber. 

A subscriber may opt to receive a hardcopy (i.e., paper) of the report, 
such as a person who is unable or othenwise unwilling to retrieve the information 
electronically. If the subscriber takes the paper delivery option, the service provider 
may creates an ASCII printstream file and a .EXE file. The service provider then 
30 generates the report according to the subscriber's instructions and delivers a paper 
copy to the subscriber. 
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In accordance with another embodiment related to the web distribution 
embodiment shown in FIG. 6, delivery of the report data may also be delivered to 
subscriber wireless devices, such as wireless application protocol (WAP) devices. 
Generally, WAP is a set of protocols that takes into account characteristics and 

5 functionality of Internet standards as well as standards for wireless services. It is an 
open standard, independent of wireless network standards. The motivations for 
WAP are primarily a result of physical and logical limitations of small wireless 
devices, such as limited keyboards and displays, limited bandwidth, limited memory 
and processing capabilities, and limited battery power. A markup language, referred 

10 to as the wireless markup language (WML), is used for authoring services designed 
to fit these smaller, and often portable, hand-held devices that have a considerably 
limited display area as compared to their desktop counterparts targeted by HTML. 
Another feature of WAP services is the availability of supporting more advanced 
functional tasks using WMLScript, which is at least loosely analogous to utilizing 

15 JavaScript in connection with HTML (HyperText Markup Language). The functional 
enhancements available through WMLScript include procedural logic and 
computational functions to WAP-based sen/ices. 

A subscriber may therefore utilize a WAP-compliant wireless device to 
receive the report data via the wireless device. This can be performed periodically, 

20 or the subscriber may request the report data. Such a request may be transmitted 
via a wireless network to a WAP gateway using a Uniform Resource Locator (URL), 
generally using the Wireless Session Protocol (WSP), which is essentially a binary 
version of HTTP. The URL addresses the requested information on a network, such 
as a server coupled to the Internet. The server returns the requested content to the 

25 WAP gateway, and is ultimately perceivable at the subscriber's WAP terminal. In 
such an embodiment, a subscriber could obtain on-demand report data via a WAP- 
compliant device, such as a WAP cell phone or other portable, wireless device. 

Subscribers who choose web or diskette delivery may also be provided 
with report-generating software, which is processed by the subscriber's computing 

30 device. The subscriber uses the report generating software to process the delivered 
data files, including the call detail data 90, and to generate reports relating to the call 
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detail data. The subscriber may, if desired, view the raw call detail data 90, a 
sample of which is provided in FIG. 8. 

The particular embodiment of call detail data illustrated in FIG. 8 
includes the following fields: call date 132, call time 134, destination number 136, 
5 calling party number 138, call type 140 (incoming, outgoing), call disposition 142, 
call status 144, call duration 146 (in tenths of seconds), calling party name 148, 
postal (zip) code 150 of the calling party, longitude 152 and latitude 154 of the 
calling party, and the value 156 assigned to the longitude/latitude specification. The 
call disposition (disp) 142 and call status (stat) 144 fields work together to encode 

1 0 information about the call. For example, if call stat = 1 and call disp = 0, the call was 
answered. If call stat = 0 and call disp = 2, the line was busy. If call stat = 0 and call 
disp = 3, the call was not answered. Other items can be encoded as well. 

FIG. 1 0 is a flow diagram illustrating representative examples of 
delivery features associated with the call reporting methodology of the present 

15 invention. Collected call transaction data is received 200, and the call transaction 
data is processed 202 for each subscriber as described above. Call transaction 
data may be collected at any appropriate communication hub, such as a switch, 
router, bridge, etc., and in one embodiment is collected at a telephone switch. As 
described above, call transaction processing 202 includes converting the call record 

20 data into a more desirable format, such as that which is compatible with the 

system's geocoding software and/or report-generating software. The processing 
also includes matching the received call transaction data to a particular subscriber. 
The call transaction data may be audited and the validity of the data determined as 
part of the processing. Data processing may also include geocoding the data, such 

25 as associating a geographic region corresponding to the location of the remote (i.e., 
non-subscriber) party of each call. Processing may also involve aggregating the call 
transaction records and geocoded data into a transportable file prior to delivery. 

The call transaction data is delivered 204 to the subscriber. Various 
delivery manners may be employed, including delivering a hardcopy 206 of the data, 

30 faxing 208, or providing an electronic copy via storage media 21 0 such as magnetic 
and optical disks, tapes, CD-ROMs, etc. The information may be delivered via a 
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network, such as the Internet 212, or may be delivered by wireless 214 
methodologies and/or WAP 21 6. Audio delivery may also be utilized, such as 
through live or recorded voice 218. 

Another particularly beneficial delivery method in accordance with the 

5 present Invention is electronic mail (e-mail) delivery 220. For example, the data files 
may be delivered as an e-mail attachment, and processed by the subscriber's 
computing device using the report-generating software. In another particularly 
beneficial embodiment, the e-mail delivery according to the present invention 
provides a presentation of the call detail data as a report in the e-mail body itself. 

1 0 Other embodiments may instead, or may additionally, provide an electronic 

document attachment that the subscriber can access or "open" using application 
software available to the subscriber. The subscriber is therefore provided with 
various report viewing options in accordance with the e-mail delivery aspect of the 
invention. The e-mail delivery implementation is described in greater detail below. 

15 FIG. 1 1 is a flow diagram illustrating one embodiment of a call 

reporting methodology utilizing e-mail delivery in accordance with the invention. 
Certain parameters may be identified in advance, as shown at block 230. These 
parameters may include the frequency or times that e-mail reports are to be 
dispatched to subscribers. For example, in one embodiment of the invention, e-mail 

20 reports are dispatched to subscribers at a predetermined frequency, such as each 
day, week, etc. Another embodiment contemplates fixed dates, such as preselected 
calendar dates. In another embodiment, other parameters may determine when the 
e-mail delivery is to be effected, such as reaching a predetermined number of call 
transactions for one, more, or the collective group of subscribers. In yet other 

25 embodiments, these parameters may be set by the subscribers, either dynamically 
or in advance. In this manner, subscribers may decide to change the periodicity of 
when e-mail reports are received, or may make real-time requests for immediate call 
report delivery. As can be seen, a wide variety of parameters may be identified to 
configure e-mail delivery options and to perform any number of predetermined 

30 functions. 

The call data is collected 232, as previously described. Depending on 
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the report period, it is determined 234 whether the call data for that report period 
has been posted (i.e., is available). The predetermined report period may be 
configured as part of the parameters identified at block 230, or may be fixed by the 
service provider. Whether all data for the report period has been posted may be 

5 determined by, for example, monitoring the state of a flag, monitoring for the 
expiration of a time duration, etc. 

When the criteria has been met, which in one particular embodiment is 
the passage of one calendar week, an alert will be generated 236. This alert 
triggers the generation 238 of the message content that will accompany the e-mails 

10 sent to subscribers. The message content may be generated in one or more 

formats. For example, in one embodiment, the message content for e-mails is read 
from a content table, and is provided in both text and HyperText Markup Language 
(HTML) formats. As each message is generated, it may be immediately presented 
for processing, or alternatively, as depicted in FIG. 1 1 , a predetermined number of 

1 5 e-mails may be generated before being presented for processing. Determining 
whether this queue is full, as determined at decision block 240, determines when 
the e-mails will be processed. For example, one embodiment of the invention 
utilizes an e-mail generation queue that upon reaching twenty queued messages, 
the queue is released for processing. 

20 The messages are then processed 242 for each subscriber. 

Processing the e-mails includes locating each subscriber's e-mail address and 
creating an e-mail message to that user's e-mail address. The e-mails are then 
dispatched 244 to the user. If more e-mails are available for processing as 
determined at decision block 246, processing returns to block 242. The e-mail 

25 generation and processing functions are described in greater detail below. 

In accordance with the present invention, a variety of e-mail formats 
may be used. The format may be text, HTML, or other format. The main e-mail 
message may be provided in a first format, such as HTML, and additional alternative 
formats may be provided at e-mail attachments. One beneficial aspect of e-mail 

30 delivery is the ability to provide the call report in a useful format for the subscriber in 
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the body of the e-mail, so that the subscriber's e-mail software presents the report to 
the subscriber without having to open additional software to view the report. 

FIG. 12 provides an example of an e-mail report layout 250 as 
received by a subscriber. The e-mail report includes an e-mail address of the entity 

5 sending the e-mail, where the e-mail domain 252 identifies the entities domain that 
may be available for return e-mail. In one embodiment, the e-mail domain 252 may 
be a telephone company who sponsors the call reporting service, or may be an 
address corresponding to a hosting service. The e-mail recipient 254 is the e-mail 
address of the service subscriber. 

1 0 This example e-mail format includes various information fields for the 

subscriber. The report period field 256 identifies the period for which the call report 
covers. In one embodiment, the report period is preset to one week, such that the 
subscriber receives a call report e-mail each week for the period identified in the 
report period field 256. The report customer number field 258 identifies the 

15 telephone number in which the report pertains, e.g., the subscriber's telephone 

number. Report data field 260 includes the call transaction data as presented to the 
subscriber. This field 260 may be significantly larger than that shown in FIG. 12, 
and may in fact Include additional fields or pages available through e-mail scrolling 
or selection of hyperlinks. The example of FIG. 12 is a simplistic example provided 

20 for purposes of illustration. 

The report data field 260 includes the call data that is the subject of 
the service to the subscriber. For example, the call data in field 260 may include a 
text listing of total incoming calls for the reporting period, as well as the total 
answered, unanswered, busy, and other calls for the reporting period. Calculated 

25 statistical information may also be provided, such as the seven-day average number 
of calls per day, and the average calls per business day. The busiest calling day 
and busiest calling hour can be provided, as well as the numbers and percentages 
of calls per day. The number of calls, whether answered, unanswered, busy, etc., 
can be provided on a time segmented basis such as hourly. Numbers of calls 

30 based on the location of the other party to the call (i.e., the party on the call with the 
subscriber) can also be presented. A wide variety of relevant statistical information 
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may be provided via tiiis e-mail delivery approach. Althougli tine report data field 
260 illustrated in FIG. 12 is represented in text format, this and other information 
may be presented in graphical format, such as many types of graphs, charts, maps, 
etc. 

5 Marketing fields may also be provided, including upgrade field(s) 262 

and advertisement field(s) 264. The upgrade field 262 allows the telephone 
company and/or hosting service to present subscribers with a means to upgrade 
their service directly from the e-mail. For example, a Internet address and/or 
hyperlink 266 may be provided to allow subscribers to select the hyperlink and 

1 0 automatically be presented with an upgrade site on the Internet. Alternatively, a 
telephone number, e-mail address, or other contact information may be provided in 
connection with upgrade field 262 to allow subscribers to upgrade, cancel, or 
othenwise change their service. The advertisement fields 264 allow the telephone 
company, the hosting service, or advertisers to present advertisements to the 

15 subscribers. 

A direct cancellation field 268 may be provided to allow the subscriber 
to cancel the e-mail report or the service altogether. Other utility fields 270 may also 
be provided. In the Illustrated embodiment, utility field 270 allows a subscriber to 
identify additional individuals (such as co-workers) to receive the call report e-mail. 

20 It should be recognized that the e-mail format presented in FIG. 12 is 

for illustrative purposes only. A variety of different formats may be utilized in 
accordance with the present invention. For example, FIG. 13 illustrates various 
graphical representations of the call report data, including maps 280, graphs 282, 
charts 284, structured data such as spreadsheets 286, etc. Further, links 288 may 

25 be provided to jump to different areas of the e-mail, to web sites, or other 
destinations capable of being accessed via links. 

In order to generate e-mail reports, the message content is stored in a 
database(s). In one embodiment, database tables are used to store the appropriate 
data. A message content table 300 is shown in FIG. 14, which is used to store the 

30 content of the message that will be sent to the subscriber. In the illustrated 

embodiment, there is one row for each type of message, and each row will contain 
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the various message formats. For message type-A 302, a unique identifier is stored 
in the content ID field 304. The various message formats in the illustrated 
embodiment of FIG. 14 include at least a text format and an HTML format, where 
the content text field 306 includes the layout and format of the report using text, and 

5 the content HTIVIL field 308 includes the layout and format of the report using HTML. 
Field 31 0 represents that other message formats may also be stored as part of the 
content table 300. The state of the active field 312 identifies whether the content for 
this message is currently active and should be used for e-mail generation. Field 314 
represents that other message content may also be stored as part of the content 

10 table 300. 

The database tables may also include a user table 320 as shown in 
FIG. 15. This table is used to store all active subscribers of the call reporting 
sen/ice. In the illustrated embodiment, there is one row for each user (i.e., 
subscriber). For user-A 322, a user identification field 324 stores an identification of 

1 5 the subscriber, and the unique identification field 326 stores a unique identification 
for the subscriber used for security reasons. The line identification field 328 
identifies the telephone line to use for report generation. 

Also included as a database table is the variable table 340 shown in 
FIG. 16. This table stores the variables that can be used in the resulting message 

20 (where the message layout and format are stored in the content table 300 shown in 
FIG. 14). There is one row for each variable, and the number of variables may be 
selected as desired. Each of the variables have the database format shown in the 
variable table 340. Using variable-A 342 as an example, the associated database 
row includes a variable identification field 344 that stores a unique identifier for 

25 Identifying each variable name. The variable name field 346 stores the name of the 
variable. In one embodiment, the variable object field 348 stores the name of the 
Java object invoked for the variable name, and returns the value for the variable 
name placeholder. Where the variable object returns multiple values, the variable 
row field 350 stores the row that the variable name's value can be found. Where the 

30 variable object returns multiple values, the variable column field 352 stores the 

column that the variable name's value can be found. Field 354 represents that other 
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variable columns may also be stored as part of the variable table 340. 

As described in connection with the variable table 340, a variety of 
variables can be used in the resulting message. FIG. 17 identifies an exemplary list 
of variables that may be used in the message content, whether HTML or text-based 
5 content. The "incoming" variable 360 identifies the number of calls that came in. 
The "answered," "unanswered," "busy," and "other variables 362, 364, 366, 368 
respectively identify the number of calls that were answered, unanswered, busy, or 
were of an unknown state. The "incoming %" variable 370 identifies the percentage 
of calls that came in (e.g., 100%). The "answered %," "unanswered %," "busy %," 

10 and "other %" variables 372, 374, 376, 378 respectively identify the percentages of 
calls that were answered, unanswered, busy or in an unknown state. The "seven 
day average" variable 380 represents the average number of calls for a seven day 
period, while the "five day average" variable 382 represents the average number of 
calls for a five day period such as Monday through Friday. The "five day total" 

15 variable 384 represents the total number of calls for the five day period. The "busy 
day" variable 386 identifies the day with the most total calls, and the "busy day total" 
variable 388 represents the number of calls that occurred for the busiest day. The 
"top zip" variable 390 identifies the zip code where the most calls came from during 
the reporting period, while the "top state" variable 392 identifies the state associated 

20 with the most calls. 

It should be recognized that the variables may be made such that they 
represent incoming calls, outgoing calls, both incoming and outgoing calls, or some 
predefined combination thereof. Thus, while the illustrative embodiment described 
in connection with FIG. 17 includes variables directed to incoming calls, additional 

25 and/or different variables may be used to report outgoing calls from the subscriber's 
customer number (i.e., phone number) during the reporting period. 

As was described in connection with FIG. 1 1, the e-mail delivery 
methodology used in connection with call reporting includes e-mail generation (e.g., 
FIG. 1 1 , block 238) and e-mail processing (e.g., FIG. 1 1 , block 242). FIG. 1 8 is a 

30 flow diagram illustrating an embodiment of an e-mail generation methodology in 
accordance with the invention. The tables described above, as well as other data 
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tables, store data that is used to generate the e-mails in accordance with the 
invention. 

To generate call report e-mails, the message content is read 400 from 
the content table. In one embodiment, the content associated with each of the 

5 different message formats is read in. For example, referring briefly to FIG. 14, a text 
format may be stored in field 306, an HTML format may be stored in field 308, and 
any one or more formats may be stored in fleld(s) 310. These different message 
contents are thus retrieved as shown in block 400. 

For purposes of illustration, a variable "n" is used in the flow diagram 

1 0 of FIG. 1 4 to represent activity that occurs for each user (i.e., subscriber). It should 
be recognized that the inclusion of the variable "n" is for purposes of gaining an 
understanding of the illustrated embodiment, and does not necessarily represent a 
particular programming step. In the illustrated embodiment, this variable "n" is 
initially set to a value of one at block 402, and "user-n" shown at block 404 is 

15 therefore user-1 when n=1. 

For this first user, the appropriate user information such as the user 
identification and telephone number is read 406 from a user table, such as the user 
table 320 shown in FIG. 15. The content table shown in FIG. 14 may include 
multiple message format, and the first message format is identified as shown at 

20 block 408. For example, the first message format may be the HTML message 

format. As shown at block 410, parsing through the message content is then carried 
out for the first message format, and the content variables are replaced with the 
appropriate message content. For example, the HTML message will be parsed 
through and each content variable being replaced with the appropriate value for that 

25 subscriber. 

When this replacement is complete, it is determined 412 whether there 
are more message formats. For example, in the content table embodiment of FIG. 
14, HTML and text formats are supported as evidenced by fields 306, 308 
respectively, as well as other potential formats represented by field(s) 310. Where 
30 more message formats exist, the next message format is identified as shown at 

block 414, and the message content associated with that message format is parsed 
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and replaced as shown at block 410. 

When there are no further message formats, one or more of these 
message formats may optionally be identified as an e-mail attachment as shown at 
block 41 6. For example, the HTML message may be designated as the main e- 
5 mail, and the text message and any other messages may be designated to be 
attachments to the e-mail. It should be recognized that such designation may be 
done at any time, and the serial depiction of the flow chart of FIG. 18 is not to be 
limiting. For example, it may be determined in advance that HTML messages will be 
presented in the body of the ensuing e-mail, and the text messages will be 

1 0 presented as attachments. 

The messages associated with the user are then queued 41 8 for 
processing. For example, where the example includes an HTML message and a 
text message for a user, then both the HTML and text messages are queued for 
processing. In one embodiment these messages may be immediately sent to the e- 

15 mail processing stage. However, in the illustrated embodiment, messages are 
queued 418, and when it is determined 420 that the queue has reached a 
predetermined threshold (e.g., twenty users, forty messages, etc.), then the 
messages are released to the e-mail processing stage 426. When the threshold 
has not been reached as determined at decision block 422, (e.g., the predetermined 

20 threshold has not been reached), the process is applied to the next user. This is 
depicted by adding one to the flowchart variable "n" as shown at block 424, and 
returning to block 404 where the next user may be considered in generating the 
appropriate e-mail content. 

FIG. 19 is a flow diagram illustrating one embodiment of an e-mail 

25 processing methodology in accordance with the present invention. The first user 
(subscriber) is taken off the queue 440 for processing. The user's e-mail address is 
located in an application user (App-User) table that includes e-mail addresses of the 
subscribers, as shown at block 442. The address may be found using the user ID 
stored with the information in the queue. An e-mail message is then formulated to 

30 this user's e-mail address using the first message content, which in one embodiment 
results in an HTML e-mail message as shown at block 444. If desired, additional e- 
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mail messages may be attached in alternate formats as shown at block 446, such 
as attaching to the e-mail a text version of the call report. When the subscriber e- 
mail address, message, and attachments have been properly included, the e-mail 
message is dispatched to the target user as illustrated at block 448. 

5 Exemplary call reports were previously described in connection with 

the e-mail delivery option of the present invention. Such reports are presented to 
the subscriber using, for example, a program operating on a computer that can read 
such e-mails. For instance, any program operating on a computer that is capable of 
receiving and viewing HTML and/or text messages can be used in accordance with 

1 0 the present invention. As future e-mail formats are developed, the report generator 
available to the subscriber need only be configured to receive and view such e-mail 
format, and the call report may be viewed by the subscriber. Attachments to the e- 
mail may be sent in an unlimited number of software formats to allow the subscriber 
flexibility in the manner of viewing the report. For example, an attachment of the call 

15 report may be provided as a PDF file, in which case the user needs the appropriate 
application software program to process and view the file. 

In the context of e-mail report generators, and in the context of other 
report generators that receive reports via the Internet, storage media, etc., the report 
generator can receive the transmitted report for viewing. The report generator 

20 function was described in connection with FIG. 1 , and more particular examples are 
provided below. 

The report generator is capable of producing multitudes of different 
reports in various formats, including tables, graphs and maps. FIG. 20 illustrates a 
main screen that a user of the report generator software may first encounter. A 

25 quick summary 500 provides a brief synopsis of the call detail data. In report period 
box 502, the user can select the dates for which a given report or set of reports 
should be generated. Selecting (e.g., clicking on) the "Change Dates" button 504 
with a mouse pulls up a calendar, an illustrative example of which is provided in FIG. 
21 . The user clicks on the dates on the calendar 520 to select the report period. 

30 The user is not limited to viewing data from the most recent time period. Rather, 
data from previous time periods may also be included in the reports. 
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In the report set selection box 506 the user selects which reports are 
to be generated. The user can choose among predefined sets of reports, 
determined by the service provider. These predefined report sets lump together 
various reports that may be useful for a specific purpose such as marketing or 

5 staffing, for example. 

By clicking on the "customize report set" button 508, the user can also 
customize a report set so that each time the software Is run, a predefined set of 
reports, selected by the user, will be generated. Clicking on the "customize report 
set" button 508 accesses a menu screen 528 such as the one illustrated in FIG. 22. 

1 0 The menu In FIG. 22 lists a variety of tables, graphs and maps. Other menus listing 
various other tables, graphs and maps can be accessed by clicking on various 
buttons above the menu. To select which reports should be generated, the user 
selects (e.g., clicks on) the boxes 530 corresponding to the desired reports. In box 
532, the user can select whether to have reports generated for Incoming calls, 

1 5 outgoing calls, or both. At radio button 534, the user can select to have reports 
generated for all of its lines, for a particular line, or for a selected group of lines. 

Referring again to FIG. 20, to view the selected reports, the user clicks 
on the "view reports" button 51 0. FIG. 23 provides an example of a table 540 
generated by the system upon selection of the "view reports" button 510. The table 

20 lists all of the zip codes from which calls were received in the given time period for 
the first time, and ranks them in terms of number of calls. Such information may be 
useful in developing and analyzing marketing and advertising strategies. The data 
in this table could also be presented in graph form, as could the data from any 
generated table. 

25 FIG. 24 provides an example of a graph 550 generated by the system. 

The graph shows the quantity of the various call types (answered, busy, 
unanswered, unknown) received during each hour for the given day. Such 
information may be useful In making staffing decisions. Of course, the system can 
also be configured to suggest answers to such decisions. For example, the system 

30 can be programmed with any desired staffing or business parameters (such as a 
number of calls which can be serviced by an individual, and a maximum desired 
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number of unanswered calls). With that information, the system can analyze the 
collected information and make recommendations, such as "Add an operator from 
10:00 am to 1:00 pm on Thursdays" or "You average 20 unanswered calls between 
6:00 am and 8:00 am. Modify store hours to accommodate incoming calls as early 
5 as 6:00 am." Any other desired parameters and recommendations can be 
implemented as well. 

Some of the other tables and graphs that may be generated by the 
system include various information regarding, for example, top callers, top zip 
codes, new callers, call duration, unanswered calls and busy signals. Of course, all 
10 of this data can be reported for either incoming calls, outgoing calls, or both. 

Many reports can also be generated in map form. FIG. 25 provides an 
example of a map 560 generated by the system. The map indicates the zip codes 
from which the most calls were received by color-coding each zip code according to 
the quantity of calls. 

1 5 The software can place each call or caller on a map at its precise 

geocoded longitude and latitude. FIG. 26 provides an example of a map 570 that 
utilizes geocoded information. The map shows all incoming calls for the stated time 
period and indicates which day they were placed using color-coding. A square is 
placed for each call at the exact longitude and latitude determined by the geocoding 

20 process of block 86 in FIG. 4. Using geocoded data, the system can also map the 
location of, for example, top callers, new callers, unanswered calls and calls that 
received a busy signal. 

The foregoing description of the exemplary embodiment of the 
invention has been presented for the purposes of illustration and description. It is 

25 not intended to be exhaustive or to limit the invention to the precise form disclosed. 
Many modifications and variations are possible in light of the above teaching. Thus, 
it is intended that the scope of the invention be limited not with the particular 
representative embodiments set forth in this detailed description, but rather by the 
claims appended hereto. 
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